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The claimed invention would not have been 
obvious in view of Mattis and Graham 

Claims 1-18 describe methods and apparatus for responding to inconndng request 
messages by converting each incoming request message into an incoming canonical request 
messageexpressedinastandardformand, if the resulting incoming canonical request message 
matches a previously received and stored canonical message, the stored response previously 
transmitted in response to the previously received request message is returned to the requester. 

The Examiner concedes that the principal reference, Mattis, does not disclose converting 
an incoming request message into a canonical request message e>qjressed in f>redetermined 
standardformasclaimed. The Examiner contends, however, that the secondary reference, 
Graham, teaches converting incoming messages (service advertisement requests) into canonical 
form before they are matched against the stored advertisements, and therefore theExaminer 
concludes that it would have been obvious to modify Mattis' cache by converting incoming 
messages into standard form in order to allow different protocols to work in harmony and 
thereby increasing interoperability. 

Applicants again submit that one skilled in the art would have no reason to convert the 
incoming requests (resource names and URLS) which Mattis processes into a canonical form 
before they are stored. In the last response, applicants pointed out that Graham's protocol 
brokering mechanism is not concerned with caching and does not compare incoming requests 
with prior requests, but instead compares requests with stored data (advertising). Graham 
therefore does not determine, and does not need to determine, if an incoming request matches a 
previously received stored request. Indeed, Graham does not store and does not need to store 
fjreviously received requests. There is thus no teaching in Graham of, or any teaching of any 
reason for, converting an incoming request into canonical form for comparison with a prior 
request, and modifying Mattis in view of Graham would thus not yield the combination claimed 
by Applicants. 

In the last response, applicants also pointed out that one skilled in the art would not be 
motivated to use Graham's protocol brokering scheme in the Mattis system because all incoming 
requests in Mattis are resource names or URLs that arrive under HTTP. Hence Mattis has no 
need for a system that serves as a broker between different protocols. In his "Response to 
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Arguments" on page 6 of the outstandingacti on. Examiner stated that applicants were incorrect 
in stating that incoming names or URLs arrive under a single protocol HTTP because Mattis 
states that a FTP server is used. In this regard, the Examiner's attention is directed to Mattis' 
explanation at col. 8, line48that the FTP server 40 delivers files over an HTTP connection . The 
Examiner's attention is still further directed to Section 1.1 of the HTTP specification, Hypertext 
TrcmsferProtocol -HTTP/ 1.0, RPC 1945 (May, 1996 available at www. ietf org/rfc/rfc 1 945 .txt) 
which states that, in addition to being used to implement the World Wide Web, HTTP is "used as 
a generic protocol for communication between user agents and proxies/gateways to other Internet 
protocols, such as SMTP [ 12], NNTP [1 1], FTP [14], Gopher [1], and WAIS [8] ..." 
Accordingly, the Mattis cache as disclosed works only with the HTTP request-response protocol, 
and the only requests that the Mattis caching system processes are HTTP requests which identify 
the cached data objects by resource name or URL. 

The Examiner furthermore suggests that Mattis and Graham essentially provide the same 
service in the sense that "both receive a request from a client, convert the request into a format 
with which the system can utilize (in Mattis, the name is hashed to a value; in Graham the request 
is formatted into anXML canonical representation), they look into a registry to find a matching 
entity f and then cm object is returned to the client when a. match is found (Mattis returns the 
cached object, Graham brokers a communication between the client and the service provider), " 

Applicant submits that Mattis and Graham provide very different services and nothing 
but a hindsight effort to come up with the subject matter which applicants' claim would motivate 
one skilled in the art to combine their teachings. Graham provides a mechanism for brokering 
requests and responses among many different protocols. The Mattis system is a specific 
optimized system for caching redundant content that is identical, but has different names, while 
at the same time efficiently caching variants of content having the same name. There is no 
suggestion whatsoever in either of these references their teachings could or should be combined 
in a way that would yield the invention claimed by applicants. 

TheExaminerhasnotrespondedtoapplicants' 
arguments concerning the rejections based on Schroeder 

In the last response, applicants pointed out why the Examiner's reliance on the third 

reference, Schroeder, in his rejection of claims 2, 6-9, 1 1 and 15-18 was improper. All of these 
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claims further specify that all or part of the request messages which are translated into canonical 
form are expressed in XML. As pointed out in applicants' specification, data requests expressed 
in XML may be logically identical but have different content, for example, logically identical 
XML request messages may have different line ending characters or include different white space 
characters which change the form but not the logical meaning of the request. Applicants' 
claimed technique of converting incoming XML requests into canonical form for storage and 
comparison permits logically identical requests to be identified even though they don't have 
identical content as received. Nothing in any of the cited references discloses or suggests doing 
this. 

As the Examiner concedes in Section 8 of the final rejection, neither Mattis nor Graham 
discloses that a portion of the incoming request message be expressed in XML language or that it 
should be translated into a standard canonical XML form. Neither the caching system described 
by Mattis nor the protocol broker taught by Graham deal with the special problems associated 
with caching XML requests. 

The Examiner note s that ''''Schroeder discloses an incoming data object inXML language 
that is translatedinto a standard canonical XA4L form " But, as applicants pointed out in the 
last restx3nse. the cited oassaee of Schroederatoaraeraohs r00481 and r00491 does not deal with 
caching, but instead with "normalizing" received XML data objects (not requests) by passing 
them through standard XSL transforms. There is no suggestion in the cited passage of Schroeder 
that these "data objects" are requests or that, once "normalized" that they are stored or compared 
with previously stored prior requests. In short, there is nothing in the cited passage of Schroeder 
that suggests that incoming requests should be placed in canonical form so that they can be 
compared with previously stored canonical requests to identify prior requests that are logically 
identical to the incoming reqviest as claimed. 
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